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METHOD AND SYSTEM FOR ESTABLISHING AND MAINTAINING 
USER-CONTROLLED ANONYMOUS COMMUNICATIONS 

BACKGROUND OFTRE INy^y,^ 
Field of the invention 

The present invention relates to establishing anonyr 



between two or more parties. More specifically, the invention relates to controlling 
5 the release of confidential or sensitive information of at least one of the parties in 
establishing anonymous communications. 
Description of the Related Art 

The need for anonymous communications can be found in everyday situations 
Police hotlines solicit tips from the public to help solve a crime, often without 
10 requiringcallerstogivetheirnames. Cash rewards are often offered for the return of 
missing items with no questions asked 

One form of anonymity involves "shielded identity," where a trusted agent 
knows the identity of a masked party, but does not reveal that identity to others except 
under very special circumstances. Unless otherwise specified, the term "anonymity" 
5 is used throughout this application interchangeably with the notion of shielded 
identity. 

Shielded identity appears in a wide range of useful and commercial functions 
A company might run an employment advertisement in a newspaper with a blind 
P.O. box known only to the publisher. A grand jury could hear testimony from a 
) ^^wl^identiryisknownonlytomeprosecutorandttejudge.bm 
from the jurors, the accused, and opposing counseL A person could identify a 
criminal suspect from a lineup of people who cannot see him. A recruiter could 
contact potential candidates for a job opening without revealing the client's name. 
Witness protection programs are designed to shield the true identity of whncsses 
enrolled in the programs. Asexual harassment hotline could be set up for victims of 
sexual harassment to call in with their complaints, while promising ,o protect the 
callers' identities. 

The above examples illustrate the need for anonymity or shielded identity due 



to a fear of exposure. The need for anonymity can also be motivated by a desire for 
privacy. For instance, donors may wish to make an anonymous charitable 
contribution, an adoption agency typically shields the identity of a child's birth 
mother, a Catholic confessional offers anonymous unburdening of the soul, and local 
5 phone companies maintain millions of unlisted telephone numbers accessible only by 
special operators. 

The concepts of anonymity and shielded identity do not lend themselves to 
conventional communication systems. While it is possible to send and receive 
anonymous messages, such as a postcard with no return address or a call placed bom 

0 a pay phone, it is difficult for parties engaged in multiple communication episodes to 
remain anonymous from one another. In general, conventional communication 
systems are premised upon the notion that communicating parties know each other's 
identity. For the purposes of this invention, the term "communications system" refers 
to any system that facilitates an ongoing cycle of messages and responses. 

5 Most current communications systems, whether written or oral, do not permit 

an ongoing, multi-party, shielded identity dialogue. For example, letters need an 
address to be delivered, calling someone on the phone requires a phone number, and 
meeting face-to-face provides for visual identification. The process involved in most 
ongoing communication systems is simply not conducive to retaining concealed 

1 identities. 

Yet, in some cases, concealing identity can actually encourage or facilitate 
communication between unwilling or cautious parties. For example, a party 
negotiating a peace treaty with another may be unwilling to reveal his identity 
because, if the negotiations fail, that party might be exposed or subjected to potential 
blackmail. 

One specific example of the need for concealing identities is in the 
employment search process, where the release of the name of the hiring company {or 
the position involved) could be damaging to the company. The hiring company might 
be concerned about how potential competitors would use the knowledge that the 
company is searching for employees to upset customers who are relying on the 
stability of the company. Mere speculation that a company is searching for a new 
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presiden, could dramatically reduce the priceof the company* stock. To find 
potential candidates for the vacant position, tbe company could engage an 
employe se^hfinntota^ 

the market, or even potentiaf candidates, the company's identity until the company 
5 decides to confide in or hire a particular candidate. 

In engaging such employment search firms, however, a hiring company entails 
some risk that ^ ^ ^ ^ y,^^ 

^panysidentitytoapo^aicandi^. Search firms are generaj.y co mpensa[ed 
based upon the number of successful placements, and thus are motivated to make 

search firms could be tempted to revea, enough donation about the company for ' 
potent* cand.da.es to dtscovcr the identity of the company, or, for that matter the 
WnK^vealttecomp^ 

becountedt.pontomainuun effective control of what information is released to 
15 potential candidates, and thus are ^ to insti| , my ^ ^ ^ Qf 

confidence in fteir client about the confidential status of their search for job 
replacements. 

The use of search firms also creates inefficiencies. In dealing with a search 
^«^looli,fa.^ j *^^ k .^ wifcl|ieaiiiiii 

20 askmg a serifts of dctaiIcd ^ ^ 

vanous auction criteria, befits, option, perks, and other factors, al, wlthout ^ 
cand.datebK.wmgmenameoffl.ehiringcompar.y. In response, the search firm may 
reveal, from general to specific, ^formation about the Wring company. For instance 
■ n ^-«to q .e«io I ^th e searchfu™ m ay S ^ v ^^ tottte 
25 c.mpany.saFortuneSOOcompany.atransportafion^^^ 

^-^^rrze^ 

30 



From the outside, these actions may appear to be a type of "dance," where 
each party seeks to learn the necessary information to keep the process moving 
forward. To answer any difficult questions, the search firm, tnisted by both parties, 
facilitates an assisted dialogue between the candidate and the company. 
5 By creating this additional layer in the communication process, however, the 

amount of effort and expense incurred by the hiring party and the candidates 
increases. Further, using such a search firm creates delays in communicating 
information between the company and the candidates and increases the likelihood that 
roisundefstandings may occur. 
1 0 In addition, the success of a search firm to fill a position is limited by the 

number of candidates that the search firm contacts. Search firms may target only 
certain individuals while overlooking many other qualified candidates who. if 
contacted, would have been very interested in considering the available positions. As 
such, search firms often do not reach a large pool of potential candidates. Search 
5 fains also know that the candidates most qualified for jobs are those that are currently 
employed. Recruiters would love to be able to show these coveted employees even 
better opportunities. Unfortunately, search firms have no way of identifying and 
contacting these prime candidates. Present systems for recruiting typically rely on the 
candidate to present himself to the recruiter - at a substantial risk to the employee. No 
) system currently gives an employee the incentive and protection he needs to feel 
comfortable submitting his resume. 

Another area in which shield identity may be desirable is dating. For example, 
a person could serve as a match-maker by setting up two people with whom he is 
acquainted on a blind date. Before agreeing to go on the date, each acquaintance may 
! ask the match-maker questions about the other person and instruct the match-maker 
not to reveal his/her identity without prior authorization. Once each of the 
acquaintances feels comfortable about the other person, he/she may authorize the 
match-maker to reveal his/her identity and agree to the date. 

Again, however, the use of match-makers suffers from the same drawbacks as 
the search firms. There is little or no control over what information match-makers 
disclose. For instance, a match-maker may feel greater loyalty to one of the 
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acquaintances and willingly divulge the identity of the other acquaintance. Also, 
using match-makers slows down the communication process and can result in 
miscommunication. Finally, the number of people that a match-maker can set up is 
limited by the number of people to whom the match-maker is acquainted. 
5 Attempts have been made to automate the employment search process and 

matchmaking process. For instance, U.S. Patent No. 5, 164,897 discloses an 
automated method for selecting personnel matching certain job criteria. Databases 
storing employee qualifications are searched to identify which personnel have 
qualifications matching search criteria. Such a system, however, does not provide 
1 0 anonymous communications between the employer and the employee and does not 
provide control over the release of information stored within those systems to others. 
Thus, there is a need for a system that allows users to exercise control over the release 
of information to others and that provides efficient anonymous communication. 
SUMMARY OF THE INVFMnn N 
15 Accordingly, the present invention is directed to a communications method 

and system that obviates problems due to limitations and disadvantages of the prior 
art. 

A goal of the invention is to provide a communication system incorporating a 
central database of information supplied by one or more of parties and managed by a 
20 central administrator, where all parties to the system can manage and control the 

release of any or all information about themselves or their identities, and where such a 
system allows for electronic-based communications between the parties without the 
necessity of revealing the identity of either party. 

Another goal of the invention to allow parties to submit criteria for searching a 
25 trusted agent's confidential database and receive a count of the number of records that 
satisfy the criteria, without revealing the identities of the parties associated with those 

A further goal of the invention is to allow a system administrator to send a 
request for authorization to release information about a party to a searching party. 
30 Other goals of the invention are to provide a system that encrypts 

communications between parties to maintain the anonymity of the parties; to 
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authenttcate searchable information contained in , central diabase for releasee 
parties; to allow one or both parties to receive compensation for contributing or 
mamtauung information accessible in a database; and to allow one party to apph 
customized scoring algorithm to information contained about other parties in a 
database. 



St,l. other g ^of misinV e„ uonaretopro ^ e ^ stOTforatnBtcdagentto 
act as an anonym remailer or yja ^ ^ ^ ^ 

w,th specific outside parties requested or identified by oneofthe parties to validate 
information about the parties. 

"> ^^-^^'heinventionistobeab.etostoreandauthenticates^ 
•nformationthatmay be provided by outside parties in a centra, database while 
aHowmgtheoutsideparties to retain control ov CT the release of respect informal 
to other parries. 

^-entionmeetsthesegoalsby^^^ 
1 5 control over the timing and release of certain information stored in a database 

where the party authorizes release of more ^ ^ ^ ^ 

^-«info^ 

therebyimprovrngfte^abilityofftereleased Fir^y, the invention 

estabhshesacommu^cati^ 

necessarily revealing thcidentity of »c party and/or me requestor to each otter The 
controHedreleaseofmfonnaaontamemv^on^ows^ 

sign.f.cant costs or be exposed to sigmficant risks iftheiridenrityw 
prematurely or indiscriminately. 

To achieve these and other objects, and in accordance with the purposes of the 
•nvenuon, as embodied and broadly described, one aspect of fte invention mcludes a 
me *^Pn>viding,he« 
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system is received from a requestor. Each party is queried to specify which respective 
party data the system is authorized to release to a requestor. Only the requested party 
data that respective parties have authorized the system to release is transmitted to the 
requestor, while the anonymity of the respective parties is maintained. 
5 In another aspect, the invention includes an apparatus for providing the 

controlled release of information. This apparatus includes a device for securely 
maintaining party data corresponding to at least one party; a device for receiving, 
from a requestor, a request for party data contained in the means for securely 
maintaining party data; a device for querying each party to specify which respective 
1 0 party data is authorized for release; and a device for transmitting to the requestor only 
the requested party data that respective parties have authorized for release, while 
securely maintaining the anonymity of the respective parties. 

BRIEF DESCRIPTION OF THE i>r a wiiv^ 
The accompanying drawings provide a further understanding of the invention 
5 and are incorporated in and constitute a part of this specification. The drawings 
illustrate preferred embodiments of the invention, and, together with the description, 
serve to explain the principles of the invention. 
In the drawings: 

Fig. 1 illustrates one embodiment of the present invention; 
) Fig. 2A illustrates a block diagram of the central controller of the system in 

accordance with the embodiment in Fig. I ; 

Fig. 2B illustrates the contents of a party data database and a requestor data 
database in accordance with the embodiment in Fig. I; 

Fig. 2C illustrates the contents of a verification database and an account 
> database in accordance with the embodiment in Fig. 1 ; 

Fig. 3 illustrates a block diagram of a party terminal in accordance with the 
embodiment in Fig. I ; 

Fig. 4 illustrates a block diagram of a requestor terminal in accordance with 
the embodiment in Fig. I ; 

Fig. 5 illustrates a flow diagram of a preferred method for establishing 
anonymous communications in accordance with this invention; 



PCT/US97/15320 

-8- 

Figs. 6A-oB illustrate a flow diagram of a preferred method for searching for 
and releasing party data in accordance with this invention; 

Fig. 7 illustrates a flow diagram of a preferred method for verifying the 
authenticity and accuracy of party data in accordance with this invention; 

Fig. 8 illustrates a flow diagram of a preferred method for opening a 
communications channel between a party and a requestor in accordance with this 
invention; and 

Fig. 9 illustrates a detailed flow diagram of a preferred method for transmitting 
party and requestor information in a communications channel in accordance with this 



PETAIIEP PFSCRIPTIOIV OF JilE JJWECTIQJj 
System Structure 

Fig. I illustrates one embodiment of an anonymous communication system 
100 according to this invention. System 100 identifies parties having characteristics 
5 of interest to a requestor, releases certain information about the identified parties to 
the requestor with authorization from the parties, releases certain information about 
the requestor to the identified parties with authorization from the requestor, and 
provides a communications channel between the identified parties and the requestor 
while maintaining their anonymity. For example, system 100 can be used to allow an 
9 employer (the requestor) to communicate with prospective candidates (the parties) 
whose background satisfies employment criteria provided by the employer without 
revealing the identity of the employer or the identities of the candidates. In a specific 
example, a software company may want to hire a programmer with 5+ years 
experience in writing C++, who is willing to live in Seattle, who will work 12-14 hour 
i days 6 days a week, who will work for between $ 100,000 to $150,000 in salary plus 
bonuses, and who wants the opportunity to work for a startup with stock options in a 
publicly-traded company that could effectively double his salary. System 100 could 
identify a dozen candidates from resumes stored in a database, release information 
about these candidates only as authorized to the company, and deliver messages 
between the company and candidates without the company ever knowing the 
candidates identities. Although the invention can be used in connection with other 
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^"^^epurposeo^^^ 

throughout the specification to describe the invention. 

200, party terminals 300, and requestor terminals 400. Central controller 200 party 

respective two-way cotronunication , ink , Patties (e.g., car^dates) ac ^ s system m 

system 100 through requestor tennina. 400. Tne flow of data from «enm„a, s 300 and 
400 ls preferably limited and controlled by central controller 200. 
1 0 Under the control of centra, controller 200. public switched telephone network 

terminal 400. In a preferred embodiment network 1 10 comprises a 
cornmercially-inmler^me^^ 

operated by, for example, a telephone company. Network U 0 may also include 
15 ^^cadonnetworksoth^^ 

w,relcss telephone network, a paging network, or the Internet. 

Centra, control.er 200 controls toe flow of data to and from party , crmmaIs 
300 and requestor terminal 400. Preferably, central controller 200 stores and 

20 terror 300 and requestor terminal 400, respectively. "Party data" comprises data 
about or corresponding to a respective party. "Requestor date" comprises data about 
or correspondmg to the requestor, h the employment search examp.e, party data 
womduKludemfonr^ntha^^ 

candidates, such as a candidate's identity, the candidate's address, the candidate's vita. 
25 statistics, the candidate's work experience, the candidate's education* background, 
and the candidate's interests. 

In one embodiment used with an employment system, each party fills out an 
electronic form that gets converted into an HTML format. ™ s presents the party's 
empfoymcnthistoryasa-hyper-resum," When reteased to a requestor, mis resume 

The hyper-links can point to additional text, QuickTime video, JPG photos or audio 
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ci. PS , allows forarichp^ionofinfonna.ion about .he party. Re^r data 

number of its eznpbyee,, .he location, of its offices, U,e industry in which ^ ' 
emptoyeroperate^the positions available and tbeir job descriptions fiscal 

collected and steed using similar .echn.ques to those outlined above for an 
employee's employment history. 

InaddiUo I ,cen^ conto „ cr200rontokthere] ^ eof ^ uKto 

-lease. Centra, confer 200 also establishes a c^unications « between 

™ C ^<*«er200^^ 

15 P^y .enninal 300 providesaparty with an interface ,o system 100 

^'^^^OOallowsa^^ 

mchcatewhichofme entered parry dau system 100 is authorized to release to a 
n^r.Wewre^^^^ 

-0 ^uestorterminaHOO. THe suture of party terminal 300 is described in greater 
detail m connection with Fig. 3. 

^^^^^^^^^^ 

cryptographtc processor 230, RAM 215, 
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ROM 220, network interface 245, and data storage device 250. Data storage device 
250 includes a plurality of databases, including party data database 255, requestor date 
database 260, verification database 270, and account database 275, as well as program 
instructions (not shown) for CPU 205. CPU 205 is connected to each of the elements 
5 of central controller 200. 

The databases in data storage device 250 are preferably implemented as 
standard relational databases capable of supporting searching and storing multimedia 
information such as text, video, QuickTime movies, photographs, and audio. Fig. 2B 
illustrates exemplary record layouts for party data database 255 and requestor data 
10 database 260, and Fig. 2C illustrates record layouts for verification database 270 and 
account database 275. Each record layout preferably comprises a two-dimensional 
array of information with one column for "Field Name" and another column for "Field 
Characteristic." The rows correspond to respective fields. 

The "authorization profile" field 256 preferably comprises a list of rules for 
1 5 releasing party or requestor data. For example, the rules could simply include a list of 
companies to which party data is not to be released, or include characteristics of 
certain companies to which party data can be released, such as companies that are in 
the Fortune 500 and have stock option plans. 

Verification database 270 preferably includes cross-referencing fields (not 
20 shown) to party data database 255 and requestor data database 260. This allows 
indexing by verified information as well as other types of searches. 

CPU 205 executes program instructions stored in RAM 2 1 5, ROM 220, and 
data storage device 250 to perform various functions described in connection with 
Figs. 5-9. In a preferred embodiment, CPU 205 is programmed to maintain data, 
25 including party data and requestor data, in storage device 250. CPU 205 receives 
party data and requestor data from network 1 10 through network interface 245 and 
stores the received party data and requestor data in databases 255 and 260, 
respectively. CPU 205 is also programmed to receive and store information in party 
database 255 and requestor database 260 indicating which of the party data and 
30 requestor data respective parties and requestors have authorized for release. Upon 
receipt of a request for authentication, CPU 205 transmits a verification request to a 
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verification authority to authenticate the origin, authorship, and integrity of the party 
data and requestor data stored in databases 255 and 260, respectively, and maintains a 
record of the verification request in database 270. 

CPU 205 is also preferably programmed to search databases 255 and 260 and 
5 transmit information in response to the search. CPU 205 receives a search request 
containing certain criteria and searches the databases of storage device 250 to find 
matches. Based upon the search, CPU 205 releases certain information to the 
requestor and the parties. Also, CPU 205 preferably assigns pseudonyms to each 
party and requestor, and stores the pseudonyms in databases 255 and 260 
10 respectively. The pseudonyms can include coded identifiers, web page addresses, 
bulletin board addresses, pager numbers, telephone numbers, e-mail addresses, voice 
mail addresses, facsimile telephone numbers, and postal mail addresses. 

CPU 205 receives search criteria pertaining to parties of interest to the 
requestor and searches database 255 to identify parties whose party data satisfies tie 
15 search criteria. There are a number of search techniques that can be used including 
keyword, fuzzy logic, and natural language search tools. For example, an employer 
could search for candidates with the following criteria: "two years of patent writing 
experience and lives in New. England." CPU 205 compares the criteria against each 
party registered with the system using one or more search algorithms and transmits to 
20 the requestor the number of parties identified. If CPU 205 receives a request for party 
data corresponding to the identified parties, CPU 205 transmits to requestor terminal 
400 the party data that the identified parties previously authorized for release along 
with respective pseudonyms. CPU 205 can also transmit queries to party terminals 
300 inquiring whether respective parties authorize the release of additional party data. 
25 If CPU 205 receives a request for requestor data from a party, CPU 205 transmits to 
the appropriate party terminal 300 the request data that the requestor previously 
authorized for release, along with a pseudonym corresponding to the requestor. 

CPU 205 is preferably also programmed to provide an anonymous 
communications channel between party terminals 300 and requestor terminal 400. 
30 CPU 205 receives a request for an anonymous communications channel along with a 
pseudonym of s party and a requestor. In one embodiment, CPU 205 establishes 
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either a real-time or Don-real-time communications channel between the party and the 
requestor corresponding to the received pseudonyms. For example, CPU 205 could 
transmit control signals to configure network 1 10 to provide a direct telephone 
connection between the party and the requestor at their respective terminals 300 and 
5 400, thereby establishing a real-time communications channel. In another example, 
CPU 205 could receive and store electronic mail messages in electronic mailboxes 
assigned to the party and the requestor for their retrieval, thereby establishing a 
non-real-time communications channel. 

CPU 205 preferably comprises a conventional high-speed processor capable of 
10 executing program instructions to perform the function* described herein. Although 
central controller 200 is described as being implemented with a single CPU 205, in 
alternative embodiments, central controller 200 could be implemented with a plurality 
of processors operating in parallel or in series. 

RAM 215 and ROM 220 preferably comprise standard commercially-available 
15 integrated circuit chips. Data storage device 250 preferably comprises static memory 
capable of storing large volumes of data, such as one or more floppy disks, hard disks, 
CDS, or magnetic tapes. 

Network interface 245 connects CPU 205 to network 1 1 0. Interface 245 
receives data streams from CPU 205 and network 1 10 formatted according to 
:0 respective communication protocols. Interface 245 reformats the data streams 

appropriately and relays the data streams to network 1 10 and CPU 205, respectively. 
Interface 245 preferably accommodates several different communication protocols. 

Cryptographic processor 210 is programmed to encrypt, decrypt, and 
authenticate the stored data in each of the databases described above. Cryptographic 
5 processor 210 encrypts and decrypts data received by and transmitted from CPU 205. 
In a preferred embodiment, all party data and requestor data are encrypted before 
being transmitted onto network 1 10. Also, processor 210 encrypts the data before 
CPU 205 transmits such data via network 1 1 0. Any encrypted data received by CPU 
205 .s decrypted by processor 210. The cryptographic protocols used by 
crvptogr a phicprocessor2I0adescribedbe.owm^ 
Protocols." 



Fig. 3 illustrates a block diagram of party terminal 300, according to one 
embodiment of the invention. Party terminal 300 includes CPU 305, which is 

communication port 340, input device 345, and data storage device 360. Video 
5 monitor 330 is connected to video driver 325, and modem 350 is connected to 
communication port 340 and public switched phone network 1 10. 

CPU 305 executes program instructions stored in RAM 310, ROM 315 and 
information storage 370 to cany out various functions associated with party termmal 
300. InaprcfernaembcxlTO 
10 dev.ee 345, receive data from communication port 340, output queries and received 
data to video driver 325 for display on video monitor 330, and output data to 
communication port 340 for transmission by modem 350. CPU 305 preferably 
transmits the data to cryptogmphic processor 335 for encryption before outputtmg 
data to commutation port 340 for transmission to network 1 10. When CPU 305 
15 receives encrypted data, CPU 305 transmits the encrypted data to cryptographic 
processor 335 for decryption. 

CPU 305 preferably comprises a high-speed processor capable of performing 
the functions described herein. RAM 310 and ROM 315 comprise standard 
commercially-available integrated circuit chips. Information storage 370 comprises 
20 static memory capab.e of storing large volumes of dau, such as one or more of floppy 
dub, hard disks, CDs, or magnetic tapes. Information storage 370 stores program 
instructions and received data. 

Video driver 325 relays received video and text data from CPU 305 to video 
monitor 330 for display. Video monitor 330 is preferably . high video 
25 'n B ^c^^^ flb9 i vMM ^ v ^ Cryptographic processor 335 
encrypts and decrypts data in accordance with conventional encryption/decryption 
techniques and is preferably capable of decrypting code encrypted by cryptographic 
processor 210. Communication port 340 relays data between CPU 305 and modem 
350 in accordance with conventional techniques. Modem 350 preferably comprises a 
30 high-speed data transmitter and receiver. Input device 345 comprises any data entry 
device for allowing a p,*y to enter data, such as a keyboard, a mouse, a video camera, 
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or a microphone. The operation of party terminal 300 is described in greater detail in 
connection with Figs. 5-9. 

Fig- 4 illustrates a block diagram of requestor terminal 400 according to the 
invention. Terminal 400 in Fig. 4 includes CPU 405. which is connected to RAM 
5 410, ROM 415, video driver 425, cryptographic processor 435, communication port 
440, input device 445, and data storage device 460. Video monitor 430 is connected 
to video driver 425, and modem 450 is connected to communication port 440 and 
public switched telephone network 1 10. 

Terminals 300 and 400 are shown in Figs. 3 and 4 to be structurally similar 
10 though different reference numerals are used. As such, a more detailed descriptionof 
terminal 400 can be obtained by referring to the above description of terminal 300. In 
a preferred embodiment, however, terminals 300 are used by parties, whereas terminal 
400 is used by a requestor. 



15 As described above, system 100 encrypts data before transferring such data 

between system users (including both parties and requestors) and central controller 
200, thereby providing various levels of security and privacy protection. As used 
throughout this section, the term "users" refers to both parties and requestors. A book 
entitled Applied Cryptography: Protocols, Algorithms, And Source Code In C by 
20 Bruce Schneier (2d Ed, John W.ley & Sons, Inc., 1996) describes in detail numerous 
cryptographic protocols that can be used. These protocols can be understood from the 
following basic overview. 

The following notation is used throughout the description of cryptographic 
protocols: 

25 PKE A : refers to the public encryption key of user A. This can be an RSA 

public key or a key for some other public key encryption scheme. 
SKE,: refers to the secret decryption key corresponding to encryption key 

PKE A . 

PKSa: refers to the public component of user A's signature key. This can be a 

30 DSS key or a key for some other public key signature scheme. It can 

also be the same key as PKE A in public key systems like RSA. 
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refers to the private signature key corresponding to PKS A . „ ^ abo 
be the same key as SKE A in public key systems like RSA 
E ra (M): -f-to^en^uonofu,,^^^^^^^ 
encryption key PKE. 

decryption key SKE. 
E K (M): ^•o^-cryptionofrnessageMwithasv^ernce.crypuon 
algonthm and key K. It is apparent from the context whether the 
protocol uses public key or symmetric key encryption 
>0 Dk (C): ^tot^rttot^^^^^ 
encryption algorithm and key K. 

likeMDS orSHA. 

»5 A3: refeto ^-ncate na t i o„ofA a rKlB.Th i sis» n ™„ n , y ^ ed ^ ra 
describing messages, 
^^^onsysterr^^^ 

20 Ahcewanu to e^ryptan^ssageMso that on, y Bob can read it . 

1- ^^Bob'spubUcerK^nonkey.PKE^gen^,^ 
symmetric encryption key K, and encrypts it with Bob's public key 

algonthm, like Triple-DES or IDEA, and sends 
25 M, = WK),C 

where C=EJM). 

3- ^d^tbekeyKusi^hisr^vatedec^tionkey 
K-DskbPWK)) 
and uses the key to decrypt the message 
° M =° K (C) = D 1C (E K (M)). 
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which is orders of magnitude faster than the public key encryption algorithm. When a 
user encrypts a message to central controller 200 using central controller 200's public 
key, ,t .s assumed that the user and central controller 200 carry out the above protocol 
Typical signature schemes (e.g. RSA or DSS) use a key pair for creating 
5 si e-^andveriryingm^^ 

generating signatures. The transformation for generating a signature is defined in such 
awaytoon^e^^^^ 

agnature. Hence, only me owner of the key pair can generate signatures 

Theomerpartofthepair.mepublicpart.isusedtoverifysignatures.Anyor.e 

stgnature i s valid. However, it is computationally infeasible to use the public 
component to forge a signature. 

One example of such a sigmaurc scheme is the RSA public-key encryption 
system. In such a system, each user hasapublic key consisting of a modulus and an 
15 exponent,, where „ is a product of two secret primes,, and The private component 
is an exponent d such that ed=\ (mod(p-lX?-l)). 

To sign a message M with an RSA key pair, the user computes 
S = M d (modn). 

where the result S is the signature. In order to verify the sig^ture, a user simply 
20 computes 

S'-M-^MOnodn). 
Tterignature verifies correctly if the result of computing S- (mod n) is the message 
thatmesignatureisfor.i.e. S<= M (modn). Thus, a user must know d in order to 
generate a signature. 

« mac key signato e schemes, howev^ares^^,^^^ 

nencc easier to sign. 
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samc signature. Therefore, the following protocol is an RSA-like signature protocol 
which will preferably be used whenever a user or central controller 200 needs to sign 
and verify messages and will be known as S SKS (M): 
1 . Alice generates a message M which she wishes to sign. 
5 2. Alice computes h = H(M), the one-way hash ofM with a predetermined 
hashing algorithm. 
3. Alice computes 

S=h'(modn) 
which is her signature. Hence, 
9 Ss^M) = (HOKJW (mod n). 

The following protocol can be used by any user to verify Alice's signature: 

1 . Bob receives a message M and corresponding signature S, which he wants to 
verify. He believes that Alice generated the signature. 

2. Bob computes M' = (modi, ) where n is Alice's public modulus (it is 
' specified as part of PKSJ. 

3. Bob verifies that M = M\ If they match, then Alice's signature verifies 
successfully. Otherwise the verification fails. 

Most of the protocols described require public encryption keys or private 
signature keys (or both). Each user communicating with central controller 200 should 
receive encrypted messages from central controller 200 and sign messages that they 
send to central controller 200. Hence, each user in the system requires a 
public/private encryption key pair and a public^rivate signature key pair. As noted 
above, these pairs could be the same pair in systems like RSA. 

Generating a key pair, either signature or encryption, depends heavily upon the 
intended algorithm. A brief example for generating RSA encryption (and signature) 
keys is shown below. 

1. Central controller 200 determines the size for the public key. Typically.a 
768-bit key is the recommended minimum, but 1024-bits provide a better 



Central controller 200 generates two primes/, and q such thatp >sqrt(p 9 ) > q, 
and p and q are not close together (i.e. they are both roughly sqrt(n) in size, but 
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different in size by two or three bits). 

3. Central controller 200 computes n = pq. This is the public modulus. 

4. Central controller 200 chooses a public exponent e. Common choices arc 3, 
17, and 65537 (2 ,4 +l). 

5 5. Central controller 200 computes the private exponent d by finding d such that 
ed=\ (mod (p-1) (?-!)). 
Centra] controller 200 can do this using the extended Euclidean Algorithm. 
6. Central controller 200 publishes n and e as the public key. e is the public 

exponent which people use to encrypt messages to the public key user (a party, 
1 0 requestor or central controller 200) or to verify the signature (if the pair is the 

signature pair). The secret exponent, d, is what is used to decrypt messages 
sent to the user or to generate signatures. 

The primes that central controller 200 chooses are preferably chosen at 
random. If an attacker can determine p and q, then the attacker can also determine d. 

1 S Several tests exist for determining whether a randomly chosen number m is prime or 
not. Typically one chooses a random number m and then uses primality tests to 
determine the first prime greater than or equal to m. 

When encrypting a message to be transmitted or verifying a signature, there 
needs to be a way of verifying the appropriate public key. One common way is to 

20 implement a hierarchical certification system in which each valid public key has a 
corresponding key certificate. The key certificate is signed by another user's private 
signature key higher up in the key hierarchy. At the top of the hierarchy is the private 
signature key of the certificate authority, whom everyone automatically trusts. In this 
case, the certificate authority would be central controller 200. 

25 The purpose of a certificate is to bind together in some authenticated way a 

public key, and a set of statements about this public key. The most important 
statement made is usually who owns the public key. Other potentially important 
statements might deal with what the key is and is not authorized to do, and when the 
key expires. 

30 The best-known standard for key certificates is X.509. More detailed 

information on the construction of X.509 certificates can be found in CCITT, Dract 



4. Alice obtains an encryption key pair. 

5. Alice generates a key certificate for her public encryption key and signs it with 
her private signature key. 

6. Alice sends a copy of her public encryption key, along with a copy of the 
5 signed key certificate, to central controller 200. 

After carrying out this protocol, Alice has a signed signature key and a signed 
encryption key. Furthermore, any user who wishes to send an encrypted message to 
Alice or verify her signature can obtain the public key component from central 
controller 200. 

10 For most of the protocols described used in the invention, it is assumed that 

central controller 200 stores signatures and the public components for all signature 
keys used in the system. In addition, it is assumed that each user has a copy of the 
public components of both of the central controller 200's signature keys. Most 
communication in system 1 00 occurs between parties and central controller 200 and 
15 between requestors and central controller 200. Where a requestor and a party 
communicate directly, each obtains copies of the other user's public signature and 
encryption keys from central controller 200. 

System 100 may be prone to attempted infiltration, or "attacks," if the 
requestor and central controller 200 do not use an interlock protocol. Schneier et al., 
20 "Automatic Event-Stream Notarization Using Digital Signatures," in Advances in 

Cryptology, Proceedings of the Cambridge Protocols Workshop 96, Springer-Verlag, 
1996. The interlock protocol "locks" the signatures generated by both users of a 
protocol to a particular instance of the protocol. This is accomplished by having each 
user sign a packet which the other user randomly generates. This causes the protocol 
25 to be non-deterministic and hence the signatures from one instance do not apply to 
another. The interlock protocol is described briefly below. Suppose that a party 
wishes to send a message C to central controller 200: 
i- The party generates a random number and sends 
M» = R* S^R,) to Central controller 200. 
30 2. Central controller 200 verifies the party's stature. Central controller 200 
then generates a random number R, and sends 
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M i=R..S SKS .(H(M () ),R,) 
to the party. 

to central controller 200. 

so it cannot predict what M,wi« look like Wi ^ P ** 

M, will look I, ke. Hence, each of them must see the packets 

party must have the capability of ^e™, • * ,mpCrSonate 

thwansareplayattae^l^r 

information as demonstrates next s-uing 

200 will™, mm ^'>^<™**l!'°*M«»Mk, 
requestor) can mount s that she could „_ 

^H^Xtr^^ 1 ^ Bang the interlock 



The operation of system 100 is now detrrih^i • 



for providing anonymous communication in accordance whh one embodiment of the 



invention. 



As shown in Fig. 5, central controller 200 receives encrypted party data and 
encrypted req.es.or data ( s ,ep 500). Such encrypted party data and requestor data 
5 preferably originates from party terminals 300 and requestor terminal 400, 

respectively. In one embodiment, party terminals 300 prompt respective parties to 
enter party data by displaying requests for information on video monitor 330. For 
instate, in the employment search example, video monitor 330 would request 
information that may be of interest to an employer, such as the carle's identity 
10 the candidate's address, the candidate's vital statistics, the candidate's work 

experience, the candidate's educational background, and the candidate's interests The 
party would enter party data using input device 345. Cryptographic processor 335 
would encrypt the entered party data and modem 350 would transmit the encrypted 
party data to central controller 200 via network 110. 
15 Requestor termbal 400 preferably operates in a similar manner to prompt a 

requestor for requestor data, receive and encrypt the requestor data, and transmit 
enc^ted requestor data to central cornier 200. Centra! controller 200 also assigns 
a pseudonym to each party and requestor whose party data and requestor data is stored 
m databases 255 and 260, respectively. 
10 After receiving the encrypted party data and requestor data, cryptographic 

processor^ of central controller 200 decrypts the received data (step 500) CPU 
205 of central controUc-200 stores the decrypted data in databases 255 and 260, 
respectively (step 500). 
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300 (step 510). 

First, central controller 200 receives search eri^ tr~ 

«n> n- , • ° m reqUeSt ° r ,cnninal («cp 

600). ^^hc„«enan 1 a yin c 1 ude. f orexan 1 ple,ce rtain e m p,ov m e„« 
^^°-oreduc.^ 

In -sponse, centra! controller 200 searches database 255 for party data 

— rflhe ^^^ rfi|iifaihBii||biiiiiio 

P-tyda^satisryingthecnteria^e^, AKerr.Uve.y, the num^ of ^ 

those parties. 

cntena to central controller 200 (step 630), and steps 61 0 and 620 are repeated 

Otherwise, c^^^ 
party data about thoseparUes found as a result of the search (step 640). Central 
wt) and the transmission ends (step 645). 

the party data request into requestor terminal 400. which transmits the request to 
centra, control 200. Central contro.ler 200 transmits an authorization request to 

25 The party receiving the request for authonzation can indicate whether to 

of three responses into party terminal 300 (step 660). The responses are sent to 
-tralcontrone^oo. Ifcentta, control 200 r^ves a response that indicates that 
«r, party does n otautho riMre ^ 
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If, on the other hand, central controller 200 receives a response that indicates that the 
party authorizes release of some or all of its party data, central controller 200 
transmits that party data to requestor terminal 400 for the requestor (step 662). 

Central controller 200 could also receive a response asking for data about the 
5 requestor before authorizing release of its party data (step 663). If so, central 

controller 200 transmits a query to the requestor at requestor terminal 400 asking for 
authorization to release requestor daU to the party (step 670). If requestor does not 
authorize release of any requestor data to the party (step 680), central controller 200 
does not release any requestor data to the party and the transaction ends (step 685). If 
10 the requestor does authorize release of some or all of the requestor data to the party 
(step 680). central controller 200 transmits the authorized requestor data to the party 
(step 690). Central controller 200 then awaits the party's response to see whether 
central controller 200 is authorized to release party data. 

To ensure the parties' authorization to release their party data is valid, 
15 permission certificates can be used in an alternate embodiment of the present 

invention. For example, in an employment system embodiment, parties who use the 
system may not want anyone to know they are hunting for a job. Candidates may not 
want any of the people they work with to know. As a result, the party would like 
explicit control over who sees their resume. Therefore, whenever central controller 
20 200 gets a request for a release of party data, central controller 200 needs to obtain 
explicit permission from the party to send the party's data to the requestor. When a 
party decides to release his party data, he can be sure his data will be released only to 
the requestor making the request The following is a preferred protocol for a party to 
issue a permission certificate: 
25 1. A requestor "A" submits a request to release party data J and to central 
controller 200 in order to find out more about the party. 
2. Central controller 200 assigns a unique transaction ID, T, to the request and 
creates a modified request J'=<J.T). The transaction ID, T, helps ensure that 
each job description (and hence permission certificate) is unique. 
•0 3. C«tralcor^ UCT er^ b ,usm g fte^^ 

the encrypted message to the party. Central controller sends 
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H> = E?K£a(T ,S sks ^PKE x ,J')) 

to the party. The party* public key is included as part of the infection that 
cental controller 200 signs so a third party cannot forward a copy of a job 
description they received from central controller 200 to another party. 
5 4. The party decrypts the message to retrieve J', verifies centra] controller 200's 
signature, reads the request, and decides if he wants to release his party data. If 
he doesn't, then he stops the protocol here. 
5. The party generates a message M containing the foJIowing information: 
A pre-defined string which states that he gives his permission to 

0 release his party data to the requestor. 

* A hash of the request H(J>). Not* this is unique to this permission 
certificate since the transaction ID is unique to the job description. 
A string which states the details about how he wants her party data 
released, whether or not he wishes to remain anonymous, etc. 
5 6. The party signs the message, encrypts it using central controller 200's public 
encryption key and sends it to central controller 200. Hence, she sends 

M, = E,ro<M,S SItSA (M)) 
to central controller 200. 
7. Central controller 200 decrypts the message to retrieve M, verifies the parr/s 

1 signature, and transmits the part/s data to the requestor. 

Because the party signs the message that central controller 200 sent him in the 
first step, bis signature will only work for the job description that central controller 
200 sent him. Hence, central controller 200 cannot use the permission certificate for a 
different job description. This assumes, of course, that the request to release party 
data contains information unique to that request, such as a transaction ID number. 
Central controller 200 embeds the transaction ID in the request to release party data 



n an alternative embodiment, central controller 200 could assign a different 
transaction ID to each request and party. Hence, two different parties cannot easily 
30 check that they are getting the same request by comparing transaction IDs. 
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The same protocol can be used in any other situation which also requires a 
permission certificate. For example, central controller 200 needs to obtain permission 
from a requestor before releasing his requestor data to a party. 

Returning to Fig. 5, central controller 200 can receive an authentication 
5 request to verify the authenticity of the origin, authorship, and/or integrity of party 
data or requestor data (step 520). Upon receiving this request, central controller 200 
verifies the data and transmits a verification status to the party or requestor requesting 
data verification (step 520). Step 520 is described in greater detail in connection with 
Fig. 7. Central controller 200 receives a verification request from a requestor for 
1 0 verification of parry data (step 700). As described above, this verification may 

include verifying the authenticity of any one of the origin, authorship, and integrity of 
the party data stored in databases 255. 

In response, central controller 200 transmits a verification status request to a 
verification authority to verify the party data (step 7 1 0). For instance, in the 
1 5 employment services example, the party data to be verified may include a university 
from which a candidate received an advanced degree. In that case, central controller 
200 could transmit a verification status request to the candidate's purported 
educational institution to verify that the candidate did, in fact, receive an advanced 
degree from that institution. 
20 When central controller 200 receives a response to its request indicating the 

verification status of the party data, central controller 200 stores the verification status 
in verification database 270 (step 720), and transmits that verification status to the 
requestor at requestor terminal 400 (step 730). 

The method shown in Fig. 7 could be adapted to verify requestor data. In that 
25 case, central controller 200 receives a request from a party to verify requestor data and 
transmits a request to a verification authority. When central controller 200 receives 
the verification status from the verification authority, it transmits the verification 
status to the party. 

Returning to Fig. 5, central controller 200 can establish an anonymous 
30 communications channel between a party and requestor (step 530). In this way, the 
party and the requestor can reveal or request information to and from each other. As 
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described above, the communications channe. can be real-time or non-rea I -«i me Fig 
8 shows a flow diagram illustrating one embodiment of . method for opening a 
communions chapel between party tennina. 300 and request terminal 400 a„ d 
Fig. 9showsa flowdiagram illustrating one embodiment of a method for managing 
5 the communication between party terminal 300 and requestor terminal 400. 
After receiving a communications channel request from a requestor to open a 
«^ 

co.mnun.cationrequesttomepartyatpartyterminanoo^g^). PrefcrabIy me 
communication request aslcs the party whether ,t agrees ,o engage in a rea.-Ume or 
1 0 non-real-time communication with the requestor. 

If centra. controller 200 receives a response Meeting that the party does no, 
agree to engage in communicaUon with the requestor (step 820), then central 
controller 200 does not open the communication, channel and the transaction ends 
(*te P 830). If central contro.ler 200 receives a response Moating that the party 
15 agrees to the request (step 820), central controller 200 opens a communications 
channel between party terminal 300 and requestor terminal 400 (step 840) The 
communications channel can be set up as either a real-time or non-real-time 
<~™™l*Kn 6 ana„d^ 

messaging system, and a video communication system. In one embodiment, the 
20 communication, channel includes a modification processor for modifying voice 
and/or video. 

After opening the communications channel central controHer 200 debits the 
requeswsbillmgac^unts^^ 

(«ep 850). Centra. controHer 200 could also collect payment from the requestor using 
25 overpayment methods mcMing: on-file credit card, periodic statement biHuig, 
accoun.debit.arKldigitalcash. Further, in one embodiment, central control,* 200 
•n^Upaymenbtopartiesforparty activities including: aUowing cenTai 
conu.neraootomamtampartyda.inp^datadata.ase^ 
requestors, and releasing party data 

^^^^^^^^^^^^ 

co-nmumcaaonscl^m^ 
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Central controller 200 receives a message from a requestor addressed to a particular 
party by pseudonym (step 900). Central controller 200 processes the message to 
remove any information that would reveal the identity of the requestor (step 910) in 
order to maintain the requestor's anonymity. Central controller 200 transmits the 
5 processed message to the party at party terminal 300 (step 920). Central controller 
200 receives a response to the message from the party, removes any information that 
would reveal the identity of the party (step 940), and transmits the processed response 
to the requestor (step 950). 

. Removing identity information may also inclade the use of voice and/or video 
10 modification processors in step 910 and 940. Steps 900-950 are repeated to allow 
multiple messages to pass between the party and the requestor, while maintaining the 
anonymity of the party and requestor. In one embodiment, fentral controller 200 
debits the requestor billing account according to the usage of the communications 
channel between the party and the requestor (step not shown). Central controller 200 
5 can measure usage of the communications channel using one of several methods, 
including: number of messages exchanged, time that central controller 200 maintains 
the communications channel, the requestor's status (i.e., premium customers pay less), 
and geographic location of party terminal 300 and/or requestor terminal 400. 

Central controller 200 collects payment for certain transactions performed. In 
) accordance with one embodiment of the invention, central controller 200 transmits a 
bill to the requestor at requestor terminal 400 for each transaction and debits the 
requestors account (step 540), which is stored in database 275 of central controller 
200. In alternative embodiments, the payment scheme can be modified or varied to 
charge either the requestor or the party or both for various transactions executed by 
system 100, and particularly central controller 200. In a further embodiment, the 
payment scheme involves paying the party for submitting information to central 
controller 200, opening a communications channel, and/or releasing party data to a 
requestor. In one embodiment of the system, a party is payed each time he authorizes 
the release of his party data to a requestor. Central controller 200 will monitor the 
transactions to ensure that parties do not release information to the same requestor 
mote than once in a given period of time. 
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As stated earlier, maintaining the anonymity of the parry and requestor can be 
important to their communications. For example, an employer may not want its 
competitors to know that it is looking to expand its staff because it may give them an 
advantage. An attacker may attempt to examine the message traffic coming in and out 
5 of central controller 200 to expose the identity of a user of the system. A way to 
prevent this type of attack is to use an anonymous mix protocol during 
communication between a party or requestor and central controller 200. 

An anonymous mix uses a protocol to make it very difficult for anyone to 
trace the path of a message which passes through the mix. The anonymous mix takes 
10 outgoing messages from central controller 200 and randomly varies both the length of 
the message as well as the timing of its delivery. An incoming message of two 
hundred kilobytes, for example, might be expanded to three hundred kilobytes by. 
adding random characters at the end. An attacker would thus be unable to correlate 
(by length of message) the incoming requestor query with requests to release party 
15 data sent to the various parties. By adding a random time delay in the processing of 
incoming requests, central controller 200 also prevents an attacker from correlating 
(based on time) incoming requests with outgoing requests. An example of the 
anonymous protocol employed in the present invention is set forth below. 
Notation and Conventions for this protocol: 

PKEn./X) represents the public-key encryption of X under public key 



PK„. 



SIGN SIU (X) represents the digital signature of X under private key SK„. 
E„}(X) represents the symmettic encryption of X under key 
PK„ represents the public key of user U. 
SK, represents the private key of user U. 
D„ represents the identification number of user U. 
X,Y represents the concatenation of X with Y. 
sd in this protocol: 

PK„ is the anonymous mix public key. 

ID, is Bob's ID, 

PK, is Bob's public key. 
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d . SK, is Bob's private key. 
When Alice sends Bob a message through anonymous mix , the following 
steps could take place: 

a. Alice wishes to send message T to Bob anonymously. She first forms: 
5 K, - a random session key. 

P„ = an all-zero string of some random length. 
X 0 = PKE m ,(K„). 
M„ = X o ,E I0 (lD. > P 0 ,T). 

Alice then sends M, to the anonymous mix 180. Note that Alice may also have 
1 0 encrypted and digitally signed the message she's sending to Bob. This has no bearing 
at all on how the anonymous mix processes it P. disguises the size of the message, 
making it difficult, or virtually impossible, to correlate incoming messages with 
outgoing messages. 

b. The anonymous mix receives M,. Using X,,, anonymous mix decodes 
1 5 the random session key K„ using anonymous mix private key SK„ and then using K,, 
ID B , T and P„ are decrypted. The anonymous mix looks up Bob's public key from 
IDo, and then forms: 

K, = a random session key. 
P, = an all-zero string of some random length. 
20 X^PKIWK,). 

M, = X„E„(P„T) 

Anonymous mix waits some random amount of time before sending M, to Bob. 
During this time, it is processing many other messages, both sending and receiving 

25 c. Bob receives M,. He decrypts it using his private key, SK. and recovers T. He 

then does whatever he needs to with T. 

In order to make messages that pass through an intermediary anonymous mix 

anonymous, a large volume of messages coming in and out arc reviewed. A random 

delay involved in forwarding those messages may also be required. Otherwise, it is 
30 possible for an opponent to watch messages going into and coining out of anonymous 

mix, using this information to determine the source and destination of each message. 
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Similarly, messages must be encrypted to the anonymous mix, so that the messages 
can be decrypted and re-encrypted with a different key. Also, messages may need to 
be broken into many pieces or padded with large blocks of data, to avoid having 
message lengths give away information. Anonymous mix either knows everyone's 
5 public keys or their public keys are sent along with their identities. Every user is 
assumed to know anonymous mix's public keys. The anonymous mix, used in 
combination with encryption and digital signatures discussed earlier, provides a high 
level of anonymity for both parties and requestors. 

Anonymity may also serve to prevent a requestor and party from contacting 
) each other outside the system in order to ensure that payment is received for bringing 
the two together. In this embodiment, central controller 200 forces anonymity by 
blinding one or both parties. The requestor, for example, may not see the name of the 
party until the requestor's account has been debited. 

Figs. 8 and 9 illustrate a method in which a communications channel between 
: a party and requestor is established and managed by system 100 without either the 
party or the requestor learning the other's identity. While Figs. 8 and 9 illustrate 
methods in which central controller 200 establishes the communications channel at a 
requestor's request, in alternative embodiments, a communications channel can be 
established at a parry's request. In that case, central controller 200 receives a request 
for a communications channel from party terminal 300, transmits the request to 
requestor terminal 400, and establishes a communications channel in accordance with 
the requestor's response. 

While the invention, as embodied and described in connection with system 
1 00, can be applied to the employment search process, the invention can also be 
applied to a variety of other areas involving anonymous communications. For 
instance, system 1 00 can be used in connection with matchmaking (i.e., providing 
dating services). People, or "parties," interested in dating can enter personal data, or 
"party data," about themselves at party terminals 300. For each party, the party data 
may include the party's identity, the party's vital statistics, the party's background, and 
the party's interests. Central controller 200 and party terminals 300 receive and 
transmit the party data in the manner described above. 
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People, or "requestors,* who would like to find parties whose personal data 
satisfies their interests or tastes can enter a search request at requestor terminal 400. 
In one embodiment, requestors enter data, or "requestor data," about themselves at 
request terminal 400, which encrypts and transmits the requestor data to central 
5 controller 200. In addition, each requestor enters, at request terminal 400, a search 
request specifying attributes about people that the requestor would like to date. For 
instance, the search request may specify that the requestor is interested in identifying 
men that are at least 6' tall and are college-educated. Request terminal 400 encrypts 
the search request and transmits the encrypted search request to central controller 200 
10 for processing, as described above. 

In response to the search request, central controller 200 preferably transmits to 
requestor terminal 400 the number of people found to satisfy the criteria in the 
request, as described above in connection with Fig. 6 A. In the example given above, 
central controller 200 would transmit to requestor terminal 400 the number of people 
15 who indicated that they are men, 6' tall, and college-educated, as revealed by party 
data database 255. Central controller 200 releases party data and requestor data to the 
requestor and parties, respectively, in the manner described above in connection with 
Fig. 6B. Central controller 200 can verify data, as described in connection with Fig. 
7, and open a communications channel between a requestor and a party, as described 
20 in connection with Figs. 8 and 9. When central controller 200 opens the 
communications channel, the requestor and the party can exchange adequate 
information about themselves to decide whether to agree to a date without subjecting 
themselves to any risk if either should decide not to agree to the date. 

The employment search and dating services examples demonstrate how the 
25 invention can: allow a requestor to search for parties meeting certain criteria, allow 
parties to control the release of information about themselves, and provide a 
communications channel between a requestor and the parties while maintaining the 
anonymity of the parties and the requestor from each other. The invention, however, 
is not limited to those types of applications. Other applications include finding and 
30 interviewing consultants or freelancers for a specific project, auditioning actors and 
actresses, seeking a merger partner, and engaging in various commerce-based 
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applications. «>u'd be readily adapted for these 

without risking rctnbution ^ ^ ^ and poncy Nations 
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or party terminal 300, for central controller 200 to open a communications channel 
with the party, or the requestor. Central controller 200 would open a communications 
channel, as described above in connection with Figs. 8 and 9, to allow the party and 
the requestor to communicate, while maintaining the party's anonymity. This would 
5 allow the employer to question the employee about details relating to the incident in 
question, without the employee revealing his identity. 

In another example, system 100 could be used as a system to allow parties to 
remain anonymous while negotiating an agreement. For instance, criminals, or rule 
offenders, anonymously offer to turn themselves in, while negotiating favorable 
1 0 treatment. In this case, the criminals, or rule offenders, would represent the "parties" 
and law enforcement, or rule enforcers, would represent the "requestors." In a 
preferred embodiment, a party would enter, at party terminal 300, information ("party 
data") about his violation and data that can be independently verified as originating 
from the party claiming the violation. The party data can include the party's identity, 
1 5 which is preferably only used by system 100 for verification purposes. Party terminal 
300 would encrypt and transmit the party data to central controller 200, in the manner 
described above. A requestor would use requestor terminal 400 to access the party 
data stored in central controller 200. 

The requestor could enter a request for authentication of the party data into 
20 requestor terminal 300, which would transmit the request to central controller 200. 
Central controller 200 would verify some or all of the party data, as described above, 
and transmit a verification status message to requestor terminal 400. Upon request 
from either party terminal 300 or requestor terminal 400, central controller can 
establish an anonymous communications channel with the other terminal, provided 
25 that the party and the requestor agree to engage in the communications channel. As 
described above, this communications channel can be real-time or non-real-time. 

Under the "plea bargaining" example, the invention allows the requestor and 
the party to negotiate the terms of the party's sentence or punishment for committing 
the violation before the party reveals his identity. If negotiations fails, the party does 
30 not subject himself to any risk that the requestor will learn his identity simply because 
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WHAT IS CLAIMED IS: 

I • A method for providing the controlled release of information in a 
communication system, comprising the steps of: 

securely maintaining in the system party data corresponding to at least 

one party; 

maintained in the system; 

querying each party to specify which respective party data the system 
is authorized to release to a requestor, and 



transmitting to the requestor only the requested party data that 
10 ^^epartieshavcaumorized^ 
the anonymity of the respective parties. 

2. A method of facilitating anonymous communications between a 
requestor and parties, comprising the steps of: 

maintaining, in a database, party data about at least one party; 
15 receiving, from a requestor, search criteria; 

searching the database for party data satisfying the search criteria; and 
establishing a communications channel between the requestor and a 
selected party whose party data satisfy the search criteria, while maintaining the 
anonymity of at least one of the requestor and the selected party. 
20 3. A system for providing the controlled release of information, 



a storage device securely maintaining party data corresponding to at 
least one party; and 

a processor connected to the storage device, the processor operative to: 
receive, from a requestor, a request for party data contained in the 
storage device; 



fori 



query each party to specify which respective party data are authorized 
elease; and 
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of the respective parties. 

4. The system according to claim 3, the processor further operative to: 
receive, from respective parties, query responses specifying which party data 

are authorized for release; and 
5 authenticate authorship for each received query response. 

5. The system according to claim 4, wherein the processor authenticates 
authorship by executing a cryptographic operation using a cryptographic key. 

6. The system according to claim 3, the processor further operative to 
authenticate authorship of the request for party data 

10 7. The system according to claim 3, the processor further operative to: 

receive criteria specifying party data of interest to the requestor; and 
search the securely maintained party data to identify a group of parties whose 
respective party data satisfy the received criteria. 

8. The system according to claim 3, the processor further operative to 
1 5 provide a communications channel between the requestor and at least one selected 

party, while securely maintaining the anonymity of at least one of the requestor and 
the at least one selected party. 

9. The system according to claim 3, the processor further operative to 
transmit to a party requestor data about the requestor, while securely maintaining the 

20 requestor's anonymity. 

10. The system according to claim 3, the processor further operative to 
establish a communications channel between the requestor and a party, while 
maintaining the anonymity of the party, to allow the requestor and the party to 
negotiate an agreement. 

25 11. The system according to claim 3, wherein the party data comprise 

personal data about at least one party interested in establishing a social relationship, 

wherein the processor is further operative to: 

store requestor data about the requestor; and 
30 release, to parties corresponding to the party data transmitted to the 

requestor, requestor data. 



12. The system according to claim 3, wherein (he processor is further 
operative to: 

receive reporting data from an employee, the reporting data including data 
identifying the employee and data describing a violation committed by another; 
5 transmit, to an employer, reporting data other than the data identifying the 

employee; and 

establish a communications channel between the employer and the employee, 
while maintaining the anonymity of the employee. 

1 3. The system according to claim 3, wherein the party data comprise 
10 employment data corresponding to at least one prospective employment candidate, the 
processor further operative to: 

receive, from an employer, a request for employment data, and 
transmit to the employer only the requested employment data that respective 
candidates have authorized for release, while securely maintaining the anonymity of 
1 5 the respective candidates. 

14. A system for controlling the release of information about prospective 
employment candidates to employers, comprising: 

a storage device securely maintaining employment data corresponding 
to at least one prospective employment candidate; and 
20 a processor connected to the storage device, the processor operative to: 

receive, from an employer, a request for employment data contained in 
the storage device; 

query each candidate to specify which respective employment data is 
authorized for release; and 
25 transmit to the employer only the requested employment data that 

respective candidates have authorized for release, while securely maintaining 
the anonymity of the respective candidates. 

15. A system for allowing an employee to report, to an employer, a 
violation committed by another without revealing the employee's identity, comprising: 
30 311 in P ut device connected to receive reporting data from the employee, 

the reporting data including data identifying the employee and data describing a 
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violation committed by another, 

an output device connected to transmit, to the employer, reporting data 
other than the data identifying the employee; and 

a communications device connected to establish a communications 
5 channel between the employer and the employee, while maintaining the anonymity of 
the employee. 

16. A system for providing the controlled release of information, 
comprising: 

means for securely maintaining party data corresponding to at least one 

10 party; 

means for receiving, from a requestor, a request for party data 
contained in the means for securely maintaining party data; 

means for querying each party to specify which respective party data 
are authorized for release; and 
1 5 means for transmitting to the requestor only the requested party data 

that respective parties have authorized for release, while securely maintaining the 
anonymity of the respective parties. 
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FIG. 2A 
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Fig. 2C 
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FIG. 3 
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FIG. 7 



CENTRAL 
CONTROLLER 
RECEIVES 
REQUEST FROM 
REQUESTOR TO 
VERIFY PARTY 
DATA 

3- 

CENTRAL 
CONTROLLER 
TRANSMFTS 
REQUEST TO 
VERIFICATION 
AUTHORITY 

CENTRAL 
CONTROLLER 

RECEIVES 
VERIFICATION 
STATUS 



CENTRAL 
CONTROLLER 
TRANSMITS 
VERIFICATION 
STATUS TO 
REQUESTOR 



SUBSTITUTE SHEET (RULE 26) 



WO 98/10558 



PCT/US»7/15320 



11/12 



FIG. 8 
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